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Abstract 

Haskell's type system has outgrown its Hindley-Milner roots to the 
extent that it now stretches to the basics of dependently typed pro- 
gramming. In this paper, we collate and classify techniques for pro- 
gramming with dependent types in Haskell, and contribute some 
new ones. In particular, through extended examples — merge-sort 
and rectangular tilings — we show how to exploit Haskell's con- 
straint solver as a theorem prover, delivering code which, as Agda 
programmers, we envy. We explore the compromises involved in 
simulating variations on the theme of the dependent function space 
in an attempt to help programmers put dependent types to work, 
and to inform the evolving language design both of Haskell and of 
dependently typed languages more broadly. 

1. Introduction 

In the design of Standard ML, Milner and his colleagues achieved 
a remarkable alignment of distinctions: 1 141 1151 
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The things you write are the things you run, namely terms, 
for which abstraction (with an explicit A) is simply typed — the 
bound variable does not occur in the return type of the function. 
The things which you leave to be inferred, namely polymorphic 
type schemes, exist only at compile time and allow (outermost) 
dependent abstraction over types, with implicit application at usage 
sites instantiating the bound variables. 

An unintended consequence of Milner's achievement is that we 
sometimes blur the distinctions between these distinctions. We find 
it hard to push them out of alignment because we lose sight of 
the very possibility of doing so. For example, some have voiced 
objections to the prospect of terms in types on the grounds that 
efficient compilation relies on erasure to the dynamic fragment 
of the language. However, renegotiating the term/type distinction 
need not destroy the dynamic/static distinction, as shown by Coq's 
venerable program extraction algorithm |17|, erasing types and 
proofs from dependently typed constructions. 
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Meanwhile, Haskell's type classes |20| demonstrate the value 
of dynamic components which are none the less implicit — instance 
dictionaries. Indeed, type inference seems a timid virtue once you 
glimpse the prospect of program inference, yet some are made 
nervous by the prospect of unwritten programs being run. Similarly, 
Haskell's combination of higher kinds and constraints means that 
sometimes static types must be given explicitly, in order not only to 
check them, but also to drive the generation of invisible boilerplate. 

Milner's aligned distinctions have shifted apart, but Haskell per- 
sists with one dependent quantifier for implicit abstraction over 
static types. What counts as a 'type' has begun to stretch. Our 
Strathclyde Haskell Enhancement preprocessor [TjJ, systematized 
and sugared common constructions for building the type level ana- 
logues of run time data, together with run time witnesses to type 
level values, allowing something which was made to look like a 
dependent quantifier for explicit abstraction over dynamic terms — 
the n-type of dependent type theory — in domains simple enough 
to admit the singleton construction. Before long, Glasgow Haskell 
headquarters responded with a proper kind system for 'promoted' 
data types |22|, making possible the singletons library |5 1. The ar- 
rival of data types at the kind level necessitated polymorphism in 
kinds: Haskell is now a dependently kinded language, and although 
it is a nuisance that the kind-level V is compulsorily implicit, the 
fresh abstractions it offers have yielded considerable simplification, 
e.g., in support of generic programming (8). 

So we decided to have some fun, motivated by the reliability 
benefits of programming at a higher level of static precision, and the 
experience of doing so in prototype dependently typed languages — 
in our case, Epigram 1 12] and Agda 1 16|. There is a real sense of 
comfort which comes from achieving a high level of hygiene, and 
it is something which we want to bring with us into practical pro- 
gramming in industrial strength languages like Haskell. Of course, 
reality intervenes at this point: some desirable methods are harder 
to express than one might hope, but we can also report some pleas- 
ant surprises. We hope our experiments inform both programming 
practice with current tools and the direction of travel for Haskell's 
evolution. 

Specifically, this paper contributes 

• an analysis of how to achieve dependent quantification in 
Haskell, framed by the distinctions drawn above — we note that 
Agda and Haskell both have room for improvement; 

• practical techniques for dependently typed programming in 
Haskell, with a view to minimizing explicit proof in program 
texts; 

• an implementation of merge-sort guaranteeing the ordering in- 
variant for its output, in which the proofs are silent; 

• an algebra for tiling size-indexed boxes, fitting with precision, 
leading to an implementation of a screen editor. 
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Overview Section [2] explores variations on the theme of depen- 
dent quantification, through paradigmatic examples involving nat- 
ural numbers and vectors. Section[3]focuses on the implicit/explicit 
distinction, whilst developing standard library functionality for 
vectors, identifying areas of concern. Section [4] delivers merge- 
sort, using instance inference for proof search. Section [5] explores 
the use of data types to represent effective evidence. Section [^in- 
troduces an algebra of size-indexed boxes, which is used to build a 
text editor in Section|7] Section[8]concludes. 

Online code All of the Haskell source code for the developments 
in this paper are available at https://github.com/slindley/ 
dependent -haskell/tree/master/Hasochism. 
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2. A Variety of Quantifiers 

Haskell's DataKinds extension |22| has the impact of duplicating 
an ordinary data type, such as 

data Nat = Z | S Nat deriving (Show, Eq, Ord) 

at the kind level. It is pleasant to think that the same Nat is both 
a type and a kind, but sadly, the current conceptual separation of 
types and kinds requires the construction of a separate kind-level 
replica. 

The Nat kind is now available for deployment in the indexing 
of generalized algebraic data types, now bearing an even stronger 
resemblance to the inductive families of dependent type theories. 
The family of vectors is the traditional first example of such a 
creature, and we shall resist the contrarian urge to choose another 
because we shall need vectors later in the paper. 

data Vec :: Nat where 

VO :: VecZx 

(:>):: X — > Vec n x — > Vec (S n) x 

In Haskell, one must choose a type's order of arguments with care, 
as partial application is permitted but A-abstraction is not. Here we 
depart a little from the dependently typed tradition by giving Vec 
its length index to the left of its payload type parameter, x, because 
we plan to develop the functorial structure of each Vec n in the 
next section. 

However, type level data are useful for more than just index- 
ing data types. We may indeed compute with them, making use of 
Haskell's 'type family' extension, which allows us to define 'fami- 
lies' (meaning merely 'functions') of 'types' in the sloppy sense of 
'things at the type level', not just the pedantic sense of 'things of 
kind . 

type family (m :: Nat) :+ (n :: Nat) :: Nat 

type instance Z :+n = n 

type instance S m :+ n = S (m :+ n) 

In an intensional dependent type theory, such a definition extends 
the normalization algorithm by which the type checker decides type 
equality up to the partial evaluation of open terms. If syntactically 
distinct types share a normal form, then they share the same terms. 
Of course, functions often have algebraic properties, e.g. associa- 
tivity and commutativity, which are not obvious from computa- 
tion alone. Fortunately, one can formulate 'propositional equality' 
types, whose inhabitants constitute evidence for equations. Values 
can be transported between provably equal types by explicit appeal 
to such evidence. 



In Haskell's kernel, type equality is entirely syntactic 1 19 1. The 
above is a collection of axioms for Haskell's propositional equality, 
and every program which relies on computation must be elaborated 
in terms of explicit appeal to evidence. The translation from the 
surface language to the kernel attempts to generate this evidence 
by a powerful but inscrutable constraint solving heuristic. Experi- 
ence suggests that the solver computes aggressively, regardless of 
whether type level programs are totally recursive, so we may con- 
fidently type vector concatenation in terms of addition. 

vappend :: Vec m x — > Vec n x — > Vec (m :+ n) x 

vappend VO ys = ys 

vappend (x :> xs) ys = x :> vappend xs ys 

Note that the numbers here play an entirely static role: the flow 
of control can be determined entirely from the constructors of the 
first vector. Suppose, however, that we wish to invert concatenation, 
chopping a vector in two. 

vchop :: Vec (m :+ n) x — > (Vec m x, Vec n x) 

Unlike with vappend, we shall certainly need m at run time, and 
we shall need to refer to it explicitly in order to judge where to 
chop. However, Haskell's dependent V-quantifier is for implicit and 
exclusively static things. The standard solution is to define the run 
time replica of some static data as a singleton GADT. 

data Natty :: Nat — > ★ where 
Zy :: Natty Z 

Sy :: Natty n -> Natty (S n) 

Each type level value n in the Nat kind has a unique representative 
in the type Natty n, so analysing the latter will reveal useful facts 
about the former. The 'n-types', often written (x : S) — > T, of 
dependent type theory abstract dependently over explicit dynamic 
things. In Haskell, we can simulate this by abstracting dependently 
at the type level and non-dependently over the singleton represen- 
tative. We translate (from Agda notation to Haskell): 

(n:Nat)->T -w Vn :: Nat. Natty n T 

Thus equipped, we may write 

vchop :: Natty m — > Vec (m :+ n) x — > (Vec m x, Vec n x) 
vchop Zy xs = (VO, xs) 

vchop (Sy m) (x :> xs) = (x :> ys, zs) 
where (ys, zs) = vchop m xs 

There may be an argument from implementation inertia in favour 
of this means of dependent quantification, but it proliferates rep- 
resentations of cognate notions, which is an eccentric way to keep 
things simple. 

Moreover, we can only construct n-types with domains admit- 
ting the singleton construction — currently, simple data structures. 
At time of writing, we cannot form a Haskell analogue of 

(n:Nat) — > (zs:Vec n x) — > T[xs] 

but we expect this gap to be plugged in the near future. Promoting 
Vec n x to a kind perforce involves using numbers not only in 
terms and types, but in kinds as well. In our new, more flexible 
world, the type/kind distinction is increasingly inconvenient, and a 
clear candidate for abolition 1211 . 

Meanwhile, a further disturbance is in store if we choose to 
compute only the first component returned by vchop. Cutting out 
the suffix gives us 

vtake :: Natty m — > Vec (m :+ n) x — > Vec m x — (x) 

vtake Zy xs = VO 

vtake (Sy m) (x :> xs) = x :> vtake m xs 

but the resulting type error 

NatVec.llis:120:44: 

Could not deduce Cu2 * (nl : + nO) ) 
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from the context (m ~ 'S nl) 

bound by a pattern with constructor 

Sy :: forall (n Nat). Natty n -> Natty C'S n) , 
in an equation for 'vtake' 
at NatVec.lhs:120:10-13 
or from ( (m : + n) " 'S n2) 

bound by a pattern with constructor 

:> :: forall x (n : : Nat), x -> Vec n x -> Vec C'S n) x, 
in an equation for 'vtake' 
at NatVec.lhs: 120: 18-24 
'n2' is a rigid type variable bound by 
a pattern with constructor 

:> :: forall x Cn : : Mat), x -> Vec n x -> Vec C'S n) x, 
in an equation for 'vtake' 
at NatVec.lhs: 120: 18 
Expected type: Vec (nl :+ nO) x 

Actual type: Vec n2 x 
In the second argument of 'vtake', namely 'xs' 
In the second argument of '(:>)', namely 'vtake m xs' 
In the expression: x :> vtake m xs 

amounts to the fact that it is not clear how to instantiate n in the 
recursive call. It takes sophisticated reasoning about addition to 
realise that (m : + ) is injective. To GHC, it is just an unknown 
axiomatised function. The problem did not arise for vchop, because 
relaying the suffix, zs, from the recursive output to the result makes 
clear that the same n is needed in both places. This n is not needed 
at run time, but without it there is no way to see that the program 
makes sense. 

The upshot is that there are data which, despite being static, 
must be made explicit. One way to manifest them is via 'proxy 
types', e.g., 

data Proxy :: re — > * where 
Proxy :: Proxy i 

As you can see, the only dynamic information in Proxy i is defined- 
ness, which there is never the need to check. Kind polymorphism 
allows us to declare the proxy type once and for all. The only point 
of a proxy is to point out that it has the same type at its binding and 
its usage sites. Although it is compulsory to instantiate quantifiers 
by inference, proxies let us rig the guessing game so that GHC can 
win it. We repair the definition of vtake thus: 

vtake :: Natty m — > Proxy n — > Vec (m :+ n) x — > Vec m x 

vtake Zy n xs = VO 

vtake (Sy m) n (x :> xs) = x :> vtake m n xs 

Of course, when calling vtake, we need to get a proxy 
from somewhere. If we do not already have one, we can write 
(Proxy :: Proxy i) for the relevant type level expression t. The 
ScopedTypeVariables extension allows us to write open types. If 
we already have some other value with the same index, e.g. a sin- 
gleton value, we can erase it to a proxy with 

proxy ::/«—> Proxy i 
proxy _ = Proxy 

The vtake example shows that Haskell's V-quantifier supports ab- 
straction over data which play a relevant and computational role 
in static types but have no impact on run time execution and thus 
erasable. Most dependently typed languages, with ATS |4| being 
a notable exception, do not offer such a quantifier, which seems 
to us something of an oversight. Coq's program extraction 1171 
and Brady's compilation method |2] both erase components whose 
types show that they cannot be needed in computation, but they do 
not allow us to make the promise that ordinary data in types like 
Nat will not be needed at run time. 

Meanwhile, Agda has an 'irrelevant' quantifier, abstracting over 
data which will even be ignored by the definitional equality of the 
type system. In effect, the erasure induced by 'irrelevance' is static 
as well as dynamic, and is thus more powerful but less applica- 
ble. The Agda translation of vtake cannot make n an irrelevant 
argument, because it is needed to compute the length of the input, 
which most certainly is statically relevant. In contemporary Agda, 
it seems that this n must be present at run time. 



A further example, showing implicit quantification over data 
used statically to compute a type but erased at run time, applies 
an n-ary operator to an n-vector of arguments. 

type family Arity (n :: Nat) (x :: ★) :: * 

type instance Arity Z x = x 

type instance Arity (S n) x = x — > Arity n x 

varity :: Arity n x — > Vec n x — > x 

varity x VO = x 

varity / (x :> xs) = varity (/ x) xs 

Here, pattern matching on the vector delivers sufficient informa- 
tion about its length to unfold the Arity computation. Once again, 
Agda would allow n to remain implicit in source code, but insist on 
retaining n at run time. Meanwhile, Brady's 'detagging' optimiza- 
tion |3J would retain n but remove the constructor tag from the 
representation of vectors, compiling the above match on the vector 
to match instead on n then project from the vector. 

To sum up, we have distinguished Haskell's dependent static 
implicit V-quantifier from the dependent dynamic explicit n-types 
of dependent type theory. We have seen how to make V- static and 
explicit with a Proxy, and how to make it dynamic and explicit 
whenever the singleton construction is possible. However, we have 
noted that whilst Haskell struggles to simulate n with V-, the 
reverse is the case in type theory. What is needed, on both sides, 
is a more systematic treatment of the varieties of quantification. 

3. Explicit and Implicit 1T-Types 

We have already seen that singletons like Natty simulate a depen- 
dent dynamic explicit quantifier, corresponding to the explicit n- 
type of type theory: Agda's (x : S) — > T. Implementations of type 
theory, following Pollack's lead |18|, often support a dependent 
dynamic implicit quantifier, the {a; : S} — > T of Agda, allowing 
type constraints to induce the synthesis of useful information. The 
method is Milner's — substitution arising from unification problems 
generated by the typechecker — but the direction of inference runs 
from types to programs, rather than the other way around. 

The Haskell analogue of the implicit n is constructed with sin- 
gleton classes. For example, the following NATTY type class de- 
fines a single method natty, delivering the Natty singleton corre- 
sponding to each promoted Nat. A NATTY number is known at 
run time, despite not being given explicitly. 

class NATTY (n :: Nat) where 
natty :: Natty n 

instance NATTY Z where 

natty = Zy 

instance NATTY n => NATTY (S n) where 
natty = Sy natty 

For example, we may write a more implicit version of vtake: 

vtrunc :: NATTY m => Proxy n — > Vec (m :+ n) x — > Vec m x 
vtrunc = vtake natty 

The return type determines the required length, so we can leave the 
business of singleton construction to instance inference. 

> vtrunc Proxy (1 :> 2 :> 3 :> 4 :> VO) :: Vec (S (S Z)) Int 
1 :> 2 :> VO 

3.1 Instances for Indexed Types 

It is convenient to omit singleton arguments when the machine can 
figure them out, but we are entitled to ask whether the additional 
cost of defining singleton classes as well as singleton types is 
worth the benefit. However, there is a situation where we have 
no choice but to work implicitly: we cannot abstract an instance 
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over a singleton type, but we can constrain it. For example, the 
Applicative instance 1 13 ] for vectors requires a NATTY constraint. 

instance NATTY n =>■ Applicative (Vec n) where 
pure = vcopies natty 
(<*>) = vapp 

where vcopies needs to inspect a run time length to make the right 
number of copies — we are obliged to define a helper function: 

vcopies Vn x. Natty n — >• x — > Vec n x 

vcopies Zy x = VO 

vcopies (Sy n) x = x :> vcopies n x 

Meanwhile, vapp is pointwise application, requiring only static 
knowledge of the length. 

vapp :: Vn s t.Vec n (s — > t) — > Vec n s — > Vec n 4 

vapp VO VO = VO 

vapp (/ :> fs) (s :> ss) = f s :> vapp fs ss 

We note that simply defining (<*>) by pattern matching in place 

instance NATTY n => Applicative (Vec n) where — (x) 
pure = vcopies natty 
VO <*> VO = VO 

(/ :> fs) <*> (s :> ss)=f S :> (fs <*> ss) 

yields an error in the step case, where n~S m but NATTY m can- 
not be deduced. We know that the NATTY n instance must be a 
NATTY (S m) instance which can arise only via an instance dec- 
laration which presupposes NATTY m. However, such an argu- 
ment via 'inversion' does not explain how to construct the method 
dictionary for NATTY m from that of NATTY (S m). When we 
work with Natty explicitly, the corresponding inversion is just what 
we get from pattern matching. The irony here is that (<*>) does 
not need the singleton at all! 

Although we are obliged to define the helper functions, vcopies 
and vapp, we could keep them local to their usage sites inside the 
instance declaration. We choose instead to expose them: it can be 
convenient to call vcopies rather than pure when a Natty n value 
is to hand but a NATTY n dictionary is not; vapp needs neither. 

To finish the Applicative instance, we must ensure that Vec n 
is a Functor. In fact, vectors are Traversable, hence also Foldable 
Functors in the default way, without need for a NATTY constraint. 

instance Traversable (Vec n) where 
traverse / VO = pure VO 

traverse / (x :> xs) = (:>) <$> / x <*> traverse / xs 

instance Foldable (Vec n) where 
foldMap = foldMapDefault 

instance Functor (Vec n) where 
fmap = fmapDefault 

3.2 Matrices and a Monad 

It is quite handy that Vec n is both Applicative and Traversable. If 
we define a Matrix as a vertical vector of horizontal vectors, thus 
(arranging Matrix's arguments conveniently for the tiling library 
later in the paper), 

data Matrix :: * -> (Nat, Nat) -> * where 

Mat :: {unMat :: Vec h (Vec w a)} -> Matrix a '(w, h) 

we get transposition cheaply, provided we know the width. 

transpose :: NATTY w => Matrix a '(w, h) -> Matrix a '(h, w) 
transpose = Mat o sequenceA o unMat 

The width information really is used at run time, and is otherwise 
unobtainable in the degenerate case when the height is Z: transpose 
must know how many VOs to deliver. 

Completists may also be interested to define the Monad in- 
stance for vectors whose join is given by the diagonal of a matrix. 



This fits the Applicative instance, whose (<*>) method more di- 
rectly captures the notion of 'corresponding positions'. 

vtail :: Vec (S n) x — > Vec n x 
vtail (_ :> xs) = xs 

diag :: Matrix x '(n, n) — > Vec n x 
diag (Mat VO) = VO 

diag (Mat ((x :> _) :> xss)) = x :> diag (Mat (fmap vtail xss)) 

instance NATTY n => Monad (Vec n) where 
return = pure 

xs 3= / = diag (Mat (fmap / xs)) 

Gibbons (in communication with McBride and Paterson 1 13 1) notes 
that the diag construction for unsized lists does not yield a monad, 
because the associativity law fails in the case of 'ragged' lists of 
lists. By using sized vectors, we square away the problem cases. 

3.3 Exchanging Explicit and Implicit 

Some interplay between the explicit and implicit II-types is in- 
evitable. Pollack wisely anticipated situations where argument syn- 
thesis fails because the constraints are too difficult or too few, and 
provides a way to override the default implicit behaviour manually. 
In Agda, if / : {x : S} — > T, then one may write / {s} to give the 
argument. 

The Hindley-Milner type system faces the same issue: even 
though unification is more tractable, we still encounter terms like 
const True _L :: Bool where we do not know which type to give 
± — parametric polymorphism ensures that we don't need to know. 
As soon as we lose parametricity, e.g. in showo read, the ambiguity 
of the underconstrained type is a problem and rightly yields a type 
error. The 'manual override' takes the form of a type annotation, 
which may need to refer to type variables in scope. 

As we have already seen, the natty method allows us to extract 
an explicit singleton whenever we have implicit run time knowl- 
edge of a value. Occasionally, however, we must work the other 
way around. Suppose we have an explicit Natty n to hand, but 
would like to use it in a context with an implicit NATTY n type 
class constraint. We can cajole GHC into building us a NATTY n 
dictionary as follows: 

natter :: Natty n -s> (NATTY n =J- t) -> t 

natter Zy 4 = 4 

natter (Sy n) 4 = natter n 4 

This is an obfuscated identity function, but not in the way that it 
looks. The t being passed along recursively is successively but 
silently precomposed with the dictionary transformer generated 
from the instance NATTY n => NATTY (S n) declaration. 
Particularly galling, however, is the fact that the dictionary thus 
constructed contains just an exact replica of the Natty n value 
which natter has traversed. 

We have completed a matrix of dependent quantifiers, shown 
here for the paradigmatic example of natural numbers, 





implicit 


explicit 


static 


V(n :: Nat). 


V(n :: Nat). Proxy n — > 


dynamic 


Vn. NATTY n => 


Vn. Natty n 



involving the kind Nat, and two ways (neither of which is the type 
Nat) to give its inhabitants run time representation, NATTY and 
Natty, which are only clumsily interchangeable despite the for- 
mer wrapping the latter. We could (and in the Strathclyde Haskell 
Enhancement, did) provide a more pleasing notation to make the 
dynamic quantifiers look like n-types and their explicit instantia- 
tors look like ordinary data, but the awkwardness is more than skin 
deep. 
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3.4 The NATTY-in-Natty Question 

Recall that we defined the singleton representation of natural num- 
bers as follows. 

data Natty :: Nat — > * where 
Zy :: Natty Z 

Sy :: Natty n -» Natty (S n) 

Another possible design choice is to insert a NATTY constraint 
in the successor case, effectively storing two copies of the prede- 
cessor. This is the choice taken by Eisenberg and Weirich in the 
Singletons library (5). 

data Natty :: Nat — > * where 
Zy :: Natty Z 

Sy :: NATTY n => Natty n -> Natty (S n) 

Each choice has advantages and disadvantages. The unconstrained 
version clearly makes for easier construction of singletons, whilst 
the constrained version makes for more powerful elimination. 

Without the NATTY constraint on Sy, we can write a function 
to compute the length of a vector as follows: 

vlength :: Vec n x — > Natty n 

vlength VO = Zy 

vlength (x :> xs) = Sy (vlength xs) 

However, with the NATTY constraint on Sy, the construction be- 
comes more complex, and we must write: 

vlength :: Vec n x — > Natty n 
vlength VO = Zy 

vlength (x :> xs) = natter n (Sy rt) where n = vlength xs 

in order to bring the appropriate NATTY constraint into scope for 
the inductive case. 

Let us write a function to construct an identity matrix of size 
n. Here, we are eliminating a singleton. Without the NATTY 
constraint on Sy, we must use natter to enable the use of the 
relevant Applicative structure. 

idMatrix :: Natty n -> Matrix Int '(n, n) 
idMatrix (Sy n) = natter rt $ 

Mat ((1 :> pure 0) :> ((0:>) <$> unMat (idMatrix n))) 
idMatrix Zy = Mat VO 

However, with the NATTY constraint on Sy, we can omit 
natter, because the required constraint is brought into scope by 
pattern matching. 

idMatrix :: Natty n -> Matrix Int '(n, n) 
idMatrix (Sy n) = 

Mat ((1 :> pure 0) :> ((0:>) <$> unMat (idMatrix n))) 
idMatrix Zy = Mat VO 

For constructions like vlength it is most convenient to omit 
the NATTY constraint from the successor constructor. For elim- 
inations like idMatrix, it is most convenient to attach the NATTY 
constraint to the successor constructor. It is hard to predict which 
polarity is more likely to dominate, but the issue with elimination 
happens only when we have the explicit witness but need the im- 
plicit one. 

There is also a time/space trade-off, as including the constraint 
effectively requires storing the same information twice at each 
node, but allows for an implementation of natter by one step of 
case analysis, rather than a full recursion. 

natter :: Natty n -> (NATTY n =J- t) -» t 
natter Zy t = t 
natter (Sy n) t = t 

SHE has vacillated between the two: the first implementation did 
not add the constraint; a tricky example provoked us to add it, but 
it broke too much code, so we reverted the change. Our experience 



suggests that omitting the constraint is more convenient more of the 
time. We should, however, prefer to omit the entire construction. 

4. An Ordered Silence 

We turn now to a slightly larger example — a development of merge- 
sort which guarantees by type alone to produce outputs in order. 
The significant thing about this construction is what is missing 
from it: explicit proofs. By coding the necessary logic using type 
classes, we harness instance inference as an implicit proof search 
mechanism and find it quite adequate to the task. 

Let us start by defining ^ as a 'type' class, seen as a relation. 

class LeN (to :: Nat) (n :: Nat) where 
instance LeN Z n where 

instance LeN m n => LeN (S rre) (S n) where 

If we wanted to close this type class, we could use module abstrac- 
tion method of Kiselyov and Shan |7| which uses a non-exported 
superclass. We leave this elaboration to the interested reader. This 
LeN class has no methods, but it might make sense to deliver at 
least the explicit evidence of ordering in the corresponding GADT, 
just as the NATTY class method delivers Natty evidence. 

In order to sort numbers, we need to know that any two numbers 
can be ordered one way or the other. Let us say what it means for 
two numbers to be so orderable. 

data OWOTO :: Nat -> Nat -> * where 

LE :: LeN x y => OWOTO x y 
GE :: LeN y x => OWOTO x y 

Testing which way around the numbers are is quite a lot like 
the usual Boolean version, except with evidence. The step case 
requires unpacking and repacking because the constructors are 
used at different types. However, instance inference is sufficient to 
deduce the logical goals from the information revealed by testing. 

owoto :: Vm n. Natty m — > Natty n — > OWOTO m n 

owoto Zy n = LE 

owoto (Sy m) Zy = GE 

owoto (Sy m) (Sy n) = case owoto m n of 

LE -> LE 

GE -> GE 

Now we know how to put numbers in order, let us see how to 
make ordered lists. The plan is to describe what it is to be in order 
between loose bounds [9|. Of course, we do not want to exclude 
any elements from being sortable, so the type of bounds extends 
the element type with bottom and top elements. 

data Bound x = Bot | Val x | Top deriving (Show, Eq, Ord) 

We extend the notion of ^ accordingly, so that instance inference 
can manage bound checking. 

class LeB (a :: Bound Nat) (b :: Bound Nat) where 
instance LeB Bot b where 

instance LeN ij=> LeB (Val x) (Val y) where 
instance LeB (Val x) Top where 

instance LeB Top Top where 

And here are ordered lists of numbers: an OList / u is a sequence 
xi :< xi :<...:< x n :< ONil such that / ^ x\ ^ X2 ^ ... ^ x n ^ u. 
The x:< checks that x is above the lower bound, then imposes x as 
the lower bound on the tail. 

data OList :: Bound Nat — ¥ Bound Nat — > ★ where 
ONil :: LeB I u =>• OList I u 
(:<) :: VZ x u.LeB I (Val x) => 

Natty x -> OList (Val x) u -s> OList I u 

We can write merge for ordered lists just the same way we would if 
they were ordinary. The key invariant is that if both lists share the 
same bounds, so does their merge. 
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merge :: OList / u — > OList I u — > OList I u 

merge ONil lu = lu 

merge lu ONil = lu 

merge (x :< xu) (y :< yu) = case owoto x y of 

LE — > x :< merge xu (y :< yu) 

GE — > y :< merge (x :< xu) yu 

The branches of the case analysis extend what is already known 
from the inputs with just enough ordering information to satisfy 
the requirements for the results. Instance inference acts as a basic 
theorem prover: fortunately (or rather, with a bit of practice) the 
proof obligations are easy enough. 

Now that we can combine ordered lists of singleton numbers, 
we shall need to construct singletons for the numbers we intend to 
sort. We do so via a general data type for existential quantification. 

data Ex (p :: re — > ★) where 

Ex : : p i — > Ex p 

A 'wrapped Nat' is then a Natty singleton for any type-level 
number. 

type WNat = Ex Natty 

We can translate a Nat to its wrapped version by writing what 
is, morally, another obfuscated identity function between our two 
types of term level natural numbers. 

wrapNat :: Nat -> WNat 
wrapNat Z = Ex Zy 

wrapNat (S m) = case wrapNat m of Ex n — > Ex (Sy n) 

You can see that wrapNat delivers the WNat corresponding to the 
Nat it receives, but that property is sadly, not enforced by type. 
However, once we have WNats, we can build merge-sort in the 
usual divide-and-conquer way. 

deal [a:] -> ([»], [x]) 
deal[] =([],[]) 

deal (x : xs) = (x : zs, ys) where (ys, zs) = deal xs 

sort :: [Nat] -> OList Bot Top 
sort [] = ONil 

sort [n] = case wrapNat n of Ex n — > n :< ONil 

sort xs = merge (sort ys) (sort zs) where (ys, zs) = deal xs 

The need to work with WNat is a little clunky, compared to the 
version one might write in Agda where one Nat type serves for 
Nat and its promotion, Natty, NATTY and WNat, but Agda does 
not have the proof search capacity of Haskell's constraint solver, 
and so requires the theorem proving to be more explicit. There is 
certainly room for improvement in both settings. 

5. Evidence Combining Data with Proof 

Let us consider the operation of comparing two singleton natural 
numbers. We refine the standard Haskell Ordering type to be in- 
dexed by the natural numbers under comparison. 

As a naive first attempt, we might copy the following definition 
from McBride and McKinna [12]: 

data Cmp :: Nat — > Nat — > * where 
LTNat :: Cmp m (m :+S z) 
EQNat :: Cmp m m 
GTNat Cmp (n :+S z) n 

If m < n, then there exists some z such that n = m + (z + 1). 
Similarly if m > n then there exists some z such that m = 
n+(z + l). 

Following a comparison, it can be useful to be able to inspect 
the difference between two numbers. In the EQNat case, this is 
simply 0. In the other two cases it is z + 1, thus in each case we 
store a singleton representation of z as a witness. 



data Cmp :: Nat — > Nat — > * where 

LTNat :: Natty z — > Cmp m (m :+ S z) 
EQNat :: Cmp m m 

GTNat :: Natty z Cmp (n :+ S z) n 

Note that in more conventional dependently typed programming 
languages, such as Agda, it is not possible to write an equivalent of 
our naive definition of Cmp — the value of z must be provided as 
an argument to the LTNat and GTNat constructors. 

We can now write a comparison function that constructs a suit- 
able proof object: 

cmp :: Natty m — > Natty n — > Cmp m n 

cmp Zy Zy = EQNat 

cmp Zy (Sy n) = LTNat n 

cmp (Sy m) Zy = GTNat m 

cmp (Sy m) (Sy n) = case cmp m n of 

LTNat z -> LTNat z 

EQNat -> EQNat 

GTNat z -> GTNat z 

The procrustes function fits a vector of length m into a vector of 
length n, by padding or trimming as necessary. (Procrustes was a 
mythical Greek brigand who would make his unfortunate guests 
fit into an iron bed either by stretching their limbs or by chopping 
them off.) 

procrustes :: a — > Natty m — > Natty n — > Vec m a — > Vec n a 
procrustes p m n xs = case cmp rn n of 

LTNat z — > vappend xs (vcopies (Sy z) p) 

EQNat -> xs 

GTNat z — > vtake n (proxy (Sy z)) xs 

In both the less-than and greater-than cases, we need the evidence 
2 provided by the Cmp data type; in the former, we even compute 
with it. 

Dependently typed programming often combines testing with 
the acquisition of new data that is justified by the test — the differ- 
ence, in this case — and the refinement of the data being tested — the 
discovery that one number is the other plus the difference. We make 
sure that every computation which analyses data has a type which 
characterizes what we expect to learn. 

6. Boxes 

In this section we introduce our main example, an algebra for 
building size-indexed rectangular tilings, which we call simply 

boxes. 

6.1 Two Flavours of Conjunction 

In order to define size indexes, we introduce some kit which turns 
out to be more generally useful. The type of sizes is given by the 
separated conjunction of Natty with Natty. 

type Size = Natty :=w: Natty 

data (p :: l — > *) (q :: K — » *) :: ((-, re) — > * where 

(:&&::) :: p I -> q K — > (p :**: q) '(t, re) 

In general, the separating conjunction : ** : of two indexed type 
constructors is an indexed product whose index is also a product, 
in which each component of the indexed product is indexed by the 
corresponding component of the index. 

We also define a non-separating conjunction. 

data (p :: re *) :*: (q :: re —>*):: re — > * where 
(:&:) :: p re —> q re —> (p :*: q) k 

The non-separating conjunction :*: is an indexed product in which 
the index is shared across both components of the product. 

We will use both separating and non-separating conjunction 
extensively in Section [72| 
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6.2 The Box Data Type 

We now introduce the type of boxes. 

data Box :: ((Nat, Nat) -»*)-> (Nat, Nat) -» * where 
Stuff :: p wh — > Box p wh 
Clear :: Box p wh 

Hor :: Natty W\ — > Box p '(wi, h) — > 

Natty u>2 — > Box p 1 (W2, h) —> Box p '{w\ :+ 11)2, h) 
Ver :: Natty hi -> Box p '(w, /ii) -> 

Natty /12 — > Box p '(w, ha) — s> Box p '(w, /ti :+ ^2) 

A box b with content of size-indexed type p and size wh has type 
Box p wh. Boxes are constructed from content (Stuff), clear boxes 
(Clear), and horizontal (Hor) and vertical (Ver) composition. Given 
suitable instantiations for the content, boxes can be used as the 
building blocks for arbitrary graphical user interfaces. In Section]?] 
we instantiate content to the type of character matrices, which we 
use to implement a text editor. 

Though Box clearly does not have the right type to be an in- 
stance of the Monad type class, it is worth noting that it is a per- 
fectly ordinary monad over a slightly richer base category than the 
category of Haskell types used by the Monad type class. The ob- 
jects in this category are indexed. The morphisms are inhabitants 
of the following :— > type. 

type s :— > t = Vi.s i — > t i 

Let us define a type class of monads over indexed types. 

class Monadlx (m :: (re —>*)—> (re — > *)) where 

returnlx :: a :—> m a 

extendlx :: (a :— > m b) — > (m a :— > m b) 

The returnlx method is the unit, and extendlx is the Kleisli 
extension of a monad over indexed types. It is straightforward to 
provide an instance for boxes. 

instance Monadlx Box where 

returnlx = Stuff 

extendlx f (Stuff c) = / c 

extendlx f Clear = Clear 

extendlx f (Hor wi b± W2 ^2) = 

Hor u>i (extendlx f bi) W2 (extendlx { fe) 
extendlx f (Ver hi bi fcj 62) = 

Ver h± (extendlx f 61) ha (extendlx / 62) 

The extendlx operation performs substitution at Stuff construc- 
tors, by applying its first argument to the content. 

Monads over indexed sets, in general, are explored in depth in 
the second author's previous work 1 10 1. 

6.3 Juxtaposition 

A natural operation to define is the one that juxtaposes two boxes 
together, horizontally or vertically, adding appropriate padding if 
the sizes do not match up. Let us consider the horizontal version 
juxH. Its type signature is: 

juxH :: Size '(wi, hi) — > Size '(ui2, ft.2) — > 

Box p '(u>i, hi) — ¥ Box p '(11)2, /12) — > 
Boxp'(u>i :+u>2,Max hi /12) 

where Max computes the maximum of two promoted Nats: 

type family Max (m :: Nat) (n :: Nat) :: Nat 

type instance Max Z n = n 

type instance Max (S m) Z = S m 

type instance Max (S m) (S n) = S (Max m n) 

As well as the two boxes it takes singleton representations of their 
sizes, as it must compute on the sizes. 

We might try to write a definition for juxH as follows: 

juxH (wi :&fe: hi) (u>2 fe) 61 62 = 

case cmp hi h2 of 



LTNat n -> 

Hor wi (Ver hi bi (Sy n) Clear) W2 &2 — (x) 
EQNat -+ 

Hor wi bi v>2 62 — (x) 

GTNat n -> 

Hor wi bi u>2 (Ver h2 62 (Sy n) Clear) — (x) 

Unfortunately, this code does not type check, because GHC has no 
way of knowing that the height of the resulting box is the maximum 
of the heights of the component boxes. 

6.4 Pain 

One approach to resolving this issue is to encode lemmas, given 
by parameterised equations, as Haskell functions. In general, such 
lemmas may be encoded as functions of type: 

Vzi ... x n . Natty xi — > ... — > Natty x n — > ((Z~r) =>• t) — ► t 

where / and r are the left- and right-hand-side of the equation, and 
xi, . . Xn are natural number variables that may appear free in the 
equation. The first n arguments are singleton natural numbers. The 
last argument represents a context that expects the equation to hold. 
For juxH, we need one lemma for each case of the comparison: 

juxH (wi hi) (v)2 /12) 61 62 = 

case cmp hi /12 of 

LTNat z -> maxLT h\ z $ 

Hor W\ (Ver hi bi (Sy z) Clear) W2 &2 
EQNat -> maxEQ hi $ 

Hor wi bi u>2 b2 
GTNat z — > maxGT /12 z $ 

Hor W\ bi W2 (Ver h2 62 (Sy z) Clear) 

Each lemma is defined by a straightforward induction: 

maxLT :: Vm z t. Natty m — > Natty z — > 

((Max m (m :+ S z)~(m :+ 5 2)) =>()-> f 
maxLT Zy z t = t 
maxLT (Sy m) z t = maxLT m z t 

maxEQ :: Vm t. Natty m — > ((Max m m~m) => t) — * t 

maxEQ Zy t = t 

maxEQ (Sy m) t = maxEQ m t 

maxGT :: Vn z t. Natty n — > Natty z — > 

((Max (n :+S z) n~(rt :+ S z)) =J- t) -> t 
maxGT Zy z t = t 
maxGT (Sy n) z t = maxGT n z t 

Using this pattern, it is now possible to use GHC as a theorem 
prover. As GHC does not provide anything in the way of direct 
support for theorem proving (along the lines of tactics in Coq, say), 
we would like to avoid the pain of explicit theorem proving as 
much as possible. Thus, we choose to change tack and switch to 
an alternative approach. 

6.5 Pleasure 

In order to avoid explicit calls to lemmas we would like to obtain 
the type equations we need for free as part of the proof object. As 
a first step, we observe that this is essentially what we are already 
doing in the proof object to encode the necessary equations con- 
cerning addition. One can always rephrase a GADT as an existen- 
tial algebraic data type with suitable type equalities. For our basic 
Cmp data type, this yields: 

data Cmp Nat — > Nat — > * where 

LTNat :: ((m :+ S z)~n) =$> Natty z — > Cmp m n 
EQNat :: (m~n) => Cmp m n 

GTNat :: (m~(n :+ S z)) Natty z — > Cmp m n 

Now the fun starts. As well as the equations that define the proof 
object, we can incorporate other equations that encapsulate further 
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knowledge implied by the result of the comparison. For now we add 
equations for computing the maximum of m and n in each case. 

data Cmp :: Nat — > Nat — s> * where 

LTNat :: ((to :+S z)~n, Max to n~n) => 

Natty z — > Cmp m n 
EQNat :: (jn~n, Max m n~m) => 

Cmp m n 

GTNat (m~(n :+ S z), Max m n~m) => 
Natty z — > Cmp m n 

Having added these straightforward equalities, our definition of 
juxH now type checks without the need to explicitly invoke any 
lemmas. 

juxH :: Size '(101, hi) — > Size '(W2, h%) — > 

Box p '(wi, hi) — ¥ Box p '(ii>2, h 2 ) — > 
Box p '(wi :+ W2, Max fti fe) 
juxH (wi :&fe: /ii) (i«2 h 2 ) 61 62 = 

case cmp hi h 2 of 
LTNat z -> 

Hor wi (Ver /ii 61 (Sy 2) Clear) «q 62 
EQNat -> 

Hor wi bi w 2 62 
GTNat z -> 

Hor u>i 61 t«2 (Ver /12 62 (Sy z) Clear) 

The juxV function is defined similarly. 

As we shall see in Section|6j6] it can be useful to attach further 
equational constraints to the Cmp constructors. A limitation of our 
current formulation is that we have to go back and modify the Cmp 
data type each time we wish to add a new equation. Ideally we 
would have some way of keeping the constraints open. This seems 
fiddly to achieve with Haskell as it stands, because one appears to 
require higher-order constraints. We leave a proper investigation to 
future work. 

6.6 Cutting 

For cutting up boxes, and two-dimensional entities in general, we 
introduce a type class Cut. 

class Cut (p :: (Nat, Nat) — s> *) where 
horCut :: Natty m — > Natty n — > 

p '(m :+ n, h) — > (p '(m,h),p ' (n,h)) 
verCut :: Natty m — > Natty n — > 

p '(w,m :+ n) — > (p '(w, m), p '(w,n)) 

We can cut horizontally or vertically by supplying the width or 
height of the two smaller boxes we wish to cut a box into. Thus 
horCut takes natural numbers m and n, an indexed thing of width 
m + n and height h, and cuts it into two indexed things of height 
h, one of width m, and the other of width n. The verCut function 
is similar. 

In order to handle the case in which we horizontally cut the hori- 
zontal composition of two boxes, we need to perform a special kind 
of comparison. In general, we wish to compare natural numbers a 
and c given the equation a + b — c + d, and capture the constraints 
on a, b, c, and d implied by the result of the comparison. For in- 
stance, if a ^ c then there must exist some number 2, such that 
b = (2 + 1) + d and c = a + (z + 1). 

We encode proof objects for cut comparisons using the follow- 
ing data type. 

data CmpCuts :: Nat — > Nat — > Nat — > Nat — > * where 
LTCuts :: (6~(S z :+d), c~(a :+ S z)) => 

Natty z — > CmpCuts abed 
EQCuts (a~c, b~d) => 

CmpCuts abed 
GTCuts :: (a~(c :+ S z), d~(S z :+ b)) => 
Natty z — > CmpCuts abed 

We can straightforwardly define a cut comparison function. 



cmpCuts :: ((a :+ 6)~(c :+ d)) => 

Natty a -> Natty b -> 

Natty c -> Natty d -> 
CmpCuts abed 
cmpCuts Zy b Zy d = EQCuts 
cmpCuts Zy b (Sy c) d = LTCuts c 
cmpCuts (Sy a) b Zy d = GTCuts a 
cmpCuts (Sy a) b (Sy c) d = case cmpCuts a b c d of 

LTCuts z —¥ LTCuts z 

EQCuts -> EQCuts 

GTCuts z —¥ GTCuts z 

Now we define cuts for boxes. 

instance Cut p => Cut (Box p) where 

horCut to n (Stuff p) = (Stuff pi , Stuff p2) 

where {pi , p2) = horCut m n p 
horCut to n Clear = (Clear, Clear) 
horCut m n (Hor Wi bi W2 62) = 
case cmpCuts m n wi W2 of 

LTCuts z — > let (fen, 612) = horCut m (Sy z) bi 

in (bn, Hor (Sy z) 612 w 2 62) 
EQCuts -+(61,62) 

GTCuts z — > let (621, 622) = horCut (Sy z) n 62 
in (Hor wi bi (Sy z) 621, 622) 
horCut m n (Ver hi bi /12 62) = 

(Ver hi bn hi 621, Ver hi 612 622) 
where (&n, 612) = horCut m n bi 
(621, 622) = horCut to n 62 

verCut m n b = ... 

The interesting case occurs when horizontally cutting the hori- 
zontal composition of two sub-boxes. We must identify which sub- 
box the cut occurs in, and recurse appropriately. Note that we rely 
on being able to cut content. The definition of vertical box cutting 
is similar. 

6.7 Boxes as Monoids 

As well as monadic structure, boxes also have monoidal structure. 

instance Cut p =>• Monoid (Box p wh) where 
mempty = Clear 

mappend 6 Clear = b 

mappend Clear 6' = b' 

mappend 6@(Stuff _) _ =6 
mappend (Hor wi bi W2 62) b' = 

Hor wi (mappend 61 bl') W2 (mappend 62 b2') 
where (bl 1 , b2') = horCut wi 1112 b' 
mappend (Ver hi 61 h 2 62) 6' = 

Ver hi (mappend 61 bl') /12 (mappend 62 62') 
where (bl', b2') = verCut hi h 2 b' 

The multiplication operation 6'mappend' b' overlays b on top of b' . 
It makes essential use of cutting to handle the Hor and Ver cases. 

6.8 Cropping = Clipping + Fitting 

We can crop a box to a region. First we need to specify an suitably 
indexed type of regions.. A point identifies a position inside a 
box, where (Zy, Zy) represents the top-left corner, counting top- 
to-bottom, left-to-right. 

type Point = Natty :**: Natty 

A region identifies a rectangular area inside a box by a pair of the 
point representing the top-left corner of the region, and the size of 
the region. 

type Region = Point :**: Size 

We decompose cropping into two parts, clipping and fitting. 

Clipping discards everything to the left and above the specified 
point. The type signature of clip is: 
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clip :: Cut p => Size '(w, h) — > Point '(x, y) — > 
Box p '(w, h) — > Box p ' (w :— x, h :— y) 

where :— is type level subtraction: 

type family (m :: Nat) :- (n :: Nat) :: Nat 

type instance Z :— rt = Z 

type instance S m :— Z = S m 

type instance S m :— S n = (m :— n) 

In order to account for the subtraction in the result, we need to 
augment the Cmp data type to include the necessary equations. 

data Cmp :: Nat — > Nat — > * where 

LTNat :: ((m :+S z)~n, Max m n^n, (m :— n)>~Z) =>■ 

Natty z — > Cmp m n 
EQNat :: (m^n, Max m n~m, (m :— n)~Z) =>■ 

Cmp m n 

GTNat :: (m~(n :+ S z), Max m n~m, (m :— n)>~S z) 
Natty z — > Cmp m n 

To clip in both dimensions, we first clip horizontally, and then clip 
verically. 

In order to define clipping we first lift subtraction on types : — 
to subtract on singleton naturals /— /. 

(/-/) :: Natty m -> Natty n Natty (m n) 
Zy/-/n = Zy 
Sy m/— /Zy = Sy m 
Sy m/— /Sy n = m/—/n 

In general one needs to define each operation on naturals three 
times: once for Nat values, once for Nat types, and once for Natty 
values. The pain can be somewhat alleviated using the singletons 
library [5], which provides a Template Haskell extension to auto- 
matically generate all three versions from a single definition. 
Let us now define clipping. 

clip O h) (x y) b = 

clipV (w/-/x h) y (clipH (w :&&: h) x b) 

clipH Cut p => Size '(w, h) — > Natty x — > 

Box p '(w, h) — > Box p 1 (w :— x, h) 
clipH (w h) x b = case cmp w x of 

GTNat d — > snd (horCut x (Sy d) b) 

_ — > Clear 

clipV :: Cut p => Size '(w, h) — > Natty y — >■ 

Box p '(w, h) — > Box p '(w, h :— y) 
clipV (ui h) y b = case cmp h y of 

GTNat d — > snd (verCut y (Sy d) b) 

_ — > Clear 

Fitting pads or cuts a box to the given size. To fit in both dimen- 
sions, we first fit horizontally, and then fit vertically. 

fit :: Cut p =$> Size '{wx, hi) — > Size ' (w2, 112) — > 

Box p '(wx, hi) — > Box p '{w2, h2) 
fit (wi :&fe: hi) (w 2 :&fe: h 2 ) b = fitV hi h 2 (fitH wi w 2 b) 

fitH :: Cut p => Natty wi — > Natty w 2 — > 

Box p '(wi, h) — > Box p '(w 2 , h) 
fitH wi w 2 b = case cmp wi w 2 of 

LTNat d -> Hor wi b (Sy d) Clear 

EQNat -> b 

GTNat d fst (horCut w 2 (Sy d) b) 

fitV :: Cut p => Natty hi -> Natty h 2 -5> 

Box p '(w, hi) — > Box p '(w, h 2 ) 
fitV hi h 2 b = case cmp hi h 2 of 

LTNat d -> Ver fti 6 (Sy d) Clear 

EQNat -> 6 

GTNat d -> /st (verCut 7i 2 (Sy d) 6) 

Note that fitH and fitV do essentially the same thing as the 
procrustes function, but on boxes rather than vectors, and always 
using Clear boxes for padding. 



To crop a box to a region, we simply clip then fit. 

crop :: Cut p => Region '('(x, y), '(w, h)) — > Size '(s, t) — > 

Box p '(s, i) — > Box p '(w, h) 
crop ((x :&fe: y) (w h)) (s i) b = 

fit ((s/-/x) (t/-/y)) (w h) 

(dip (s t) (x y) b) 

A convenient feature of our cropping code is that type-level sub- 
traction is confined to the clip function. This works because in the 
type of fit the output box is independent of the size of the input 
box. 

In an earlier version of the code we experimented with a more 
refined cropping function of type: 

Cut p => Region '{'(x, y), '(w, h)) — > Size '(s, t) — > 

Box p '(s, t) -» Box p '(Min w (s x), Min h (t :- y)) 

where Min is minimum on promoted Nats. 

This proved considerably more difficult to use as we had to 
reason about interactions between subtraction, addition, and min- 
imum. Moreover, the less-refined version is often what we want in 
practice. 

7. An Editor 

We outline the design of a basic text editor, which represents the 
text buffer as a size-indexed box. Using this representation guar- 
antees that manipulations such as cropping the buffer to generate 
screen output only generate well-formed boxes of a given size. We 
will also need to handle dynamic values coming from the outside 
world. We convert these to equivalent size-indexed values using 
existentials, building on the Ex data type of Section|4]and the sep- 
arating and non-separating conjunction operators of Section [oTT] 

7.1 Character Boxes 

A character box is a box whose content is given by character 
matrices. 

type CharMatrix = Matrix Char 
type CfiarBox = Box CharMatrix 

Concretely, we will use a character box to represent a text buffer. 
We can fill an entire matrix with the same character. 

matrixChar :: Char — > Size wh — > CharMatrix wh 
matrixChar c (w h) = Mat (vcopies h (vcopies w c)) 

We can render a character box as a character matrix. 

renderCharBox :: 

Size wh — > CharBox wh — > CharMatrix wh 
renderCharBox _ (Stuff ess) = ess 
renderCharBox wh Clear = 

matrixChar ' ' wh 
renderCharBox (w _) (Ver hi bi h 2 b 2 ) = 
Mat (unMat (renderCharBox (w :&fc: hi) bi) 

'vappend' unMat (renderCharBox (w h 2 ) b 2 )) 
renderCharBox (_ h) (Hor wi bi w 2 b 2 ) = 
Mat (vcopies h vappend 'vapp' 

unMat ( renderCharBox (wi :&fe: h) bi) 'vapp' 

unMat (renderCharBox (w 2 h) b 2 )) 

We can display a character matrix as a list of strings. 

stringsOfCharMatrix :: CharMatrix wh —> [String] 
stringsOfCharMatrix (Mat vs) = 
foldMap ((:[]) o foldMap (:[])) vs 

In order to be able to cut (and hence crop) boxes with matrix 
content we instantiate the Cut type class for matrices. 

instance Cut (Matrix e) where 
horCut m _ (Mat ess) = 

(Mat (fst <$> ps), Mat (snd <$> ps)) where 
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ps = vchop m <$> ess 
verCut m _ (Mat ess) = (Mat tess, Mat bess) where 
(tess, bess) = vchop m ess 

7.2 Existentials 

In Section [4] we introduced existentially quantified singletons as a 
means for taking dynamic values and converting them into equiva- 
lent singletons. 

We now present combinators for constructing existentials over 
composite indexes. For the editor, we will need to generate a region, 
that is, a pair of pairs of singleton naturals from a pair of pairs of 
natural numbers. 

wrapPair :: (a — > Ex p) — > 
(b — > Ex q) — > 

(a, b) —> Ex (p :**: q) 
wrapPair wi w 2 (£1,2:2) = 
case ( w\ xi , w 2 x 2 ) of 

(Ex vl , Ex v2) -> Ex (vl :&&: v2) 

The wrapPair function wraps a pair of dynamic objects in a suitable 
existential package using a separated conjunction. 

type WPoint = Ex Point 
type WSize = Ex Size 
type WRegion = Ex Region 

intToNat :: Int -» Nat 
intToNat 0 = Z 

intToNat n = S (intToNat (n - 1)) 

wraplnt = wrapNat o intToNat 
wrapPoint = wrapPair wraplnt wraplnt 
wrapSize = wrapPair wraplnt wraplnt 
wrapRegion = wrapPair wrapPoint wrapSize 

We might wish to wrap vectors, but the Vec type takes the length 
index first, so we cannot use it as is with Ex. Thus we can define 
and use a Flip combinator, which reverses the arguments of a two 
argument type-operator. 

newtype Flip / a b = FlipjunFlip:: / b a} 

type WVec a = Ex (Flip Vec a) 

wrapVec :: [a] — > WVec a 
wrapVec [] = Ex (Flip VO) 

wrapVec (x : xs) = case wrapVec xs of 
Ex (Flip v) — > Ex (Flip (x :> v)) 

In fact, we wish to wrap a vector up together with its length. 
This is where the non-separating conjunction comes into play. The 
Natty representing the length of the vector and the Flip Vec a 
representing the vector itself should share the same index. 

type WLenVec a = Ex (Natty :*: Flip Vec a) 

wrapLenVec :: [a] — > WLenVec a 
wrapLenVec [] = Ex (Zy :&: Flip VO) 

wrapLenVec (x : xs) = case wrapLenVec xs of 
Ex (n Flip v) — > Ex (Sy n Flip (x :> v)) 

Similarly, we use non- separating conjunction to wrap a box with its 
size. 

type WSizeCharBox = Ex (Size :*: CharBox) 
Given a string of length w, we can wrap it as a character box of size 
(w,l). 

wrapString :: String — > WSizeCharBox 
wrapString s = case wrapLenVec s of 
Ex (n :&: Flip v) — > 

Ex ((n Sy Zy) Stuff (Mat (pure v))) 



Given a list of h strings of maximum length w, we can wrap it as a 
character box of size (w,h). 

wrapStrings :: [String] — > WSizeCharBox 
wrapStrings [] = Ex ((Zy Zy) :&: Clear) 
wrapStrings (s : ss) = 

case (wrapString s, wrapStrings ss) of 

(Ex (( W1 hi) &i), 

Ex {(w 2 h 2 ) b 2 )) -> 

Ex (((wi 'maxn' w 2 ) {h 1 /+/h 2 )) 

juxV (u>i h{) (w 2 h 2 ) 61 b 2 ) 

where maxn is maximum on singleton natural numbers: 

maxn :: Natty m — > Natty n — > Natty (Max m n) 

maxn Zy n = n 

maxn (Sy m) Zy = Sy m 

maxn (Sy m) (Sy n) = Sy (maxn m n) 

Curiously, the singletons library does not appear to provide any 
special support for existential quantification over singletons. It 
should be possible to automatically generate the code for wrap- 
ping dynamic objects in existentials. 

We note also that the tendency to use stock datatype compo- 
nents, e.g., Ex, Flip, :*: and :**:, causes extra layering of wrap- 
ping constructors in patterns and expressions. We could use a be- 
spoke GADT for each type we build in this way, but that would 
make it harder to develop library functionality. Ordinary 'let' al- 
lows us to hide the extra layers in expressions, but is no help for 
patterns, which are currently peculiar in that they admit no form 
of definitional abstraction 1 1 1. This basic oversight would be read- 
ily remedied by pattern synonyms — linear, constructor-form defi- 
nitions which expand like macros either side of the = sign. 

7.3 Cursors 

We use a zipper structure |6| to represent a cursor into a text buffer. 
We make no attempt to statically track the size of the buffer as a 
cursor, but do so when we wish to manipulate the whole buffer. 

A cursor is a triple consisting of: a backwards list of elements 
before the current position, the object at the current position, and a 
forward list of elements after the current position. 

type Cursor a m = ([a], m, [a]) 

The elements of a StringCursor are characters. 

type StringCursor = Cursor Char () 

The elements of a TextCursor are strings. The object at the current 
position is a StringCursor. 

type TextCursor = Cursor String StringCursor 

The deactivate and activate functions convert between a unit cur- 
sor and a pair of a list and its length. 

deactivate :: Cursor a () — > (Int, [a]) 
deactivate c = outward 0 c where 
outward i ([],(), xs) =(i,xs) 

outward i (x : xz, (), xs) = outward (i + 1) (xz, (), x : xs) 

activate :: (Int, [a]) — > Cursor a () 

activate (i,xs) = inward i ([],(), xs) where 

inward _ c@(_, (), []) = c 

inward 0 c = c 

inward i (xz, (), x : xs) = inward (i — I) (x : xz, (), xs) 

The whatAndWhere function uses deactivate and wrapStrings 
to generate a well-formed existentially quantified box from a 
TextCursor. 

whatAndWhere :: TextCursor -> (WSizeCharBox, (Int, Int)) 
whatAndWhere (czz, cur, ess) = (wrapStrings strs, (x, y)) 
where 
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(x, cs) = deactivate cur 

(y, strs) = deactivate (czz, (), cs : ess) 

7.4 The Inner Loop 

We give a brief overview of the editor's inner loop. The full code is 
av ailable as literate Haskell at: 

https : //github . com/slindley /dependent -haskell/tn;e/ 
master/Hasochism/Editor . Ins 

The current position in the text buffer is represented using a zip- 
per structure over an unindexed list of strings. The current position 
and size of the screen is represented as two pairs of integers. On a 
change to the buffer, the inner loop proceeds as follows. 

• Wrap the current screen position and size as a singleton region 
using wrapRegion. 

• Unravel the zipper structure using whatAndWhere to reveal the 
underlying structure of the buffer as a list of strings. 

• This invokes wrapStrings to wrap the list of strings as an 
existential over a suitably indexed CharBox. 

• Crop the wrapped CharBox according to the wrapped singleton 
region. 

• Render the result as a list of strings using stringsOfCharMatrixo 
renderCharBox. 

We take advantage of dependent types to ensure that cropping 
yields boxes of the correct size. The rest of the editor does not use 
dependent types. The wrapping functions convert non-dependent 
data into equivalent dependent data. Rendering does the opposite. 

We expect that converting back and forth between raw and 
indexed data every time something changes is expensive. We leave 
a full performance evaluation to future work. One might hope to use 
indexed data everywhere. This is infeasible in practice, because of 
the need to interact with the outside world, and in particular foreign 
APIs (including the curses library we use for our text editor). 

8. Conclusion 

We have constructed and explored the use of the static-versus- 
dynamic/explicit-versus-implicit matrix of value-dependent quan- 
tifiers in Haskell. We have observed the awkwardness, but enjoyed 
the mere possibility, of dynamic quantification and used it to build 
substantial examples of sorting and box-tiling, where the establish- 
ment and maintenance of invariants is based not just on propagation 
of static indices, but on dynamic generation of evidence. 

After some fairly hairy theorem proving, the worst of which 
we have spared you, we learned how to package proofs which 
follow a similar pattern inside GADTs of useful evidence. GHC's 
constraint solver is a good enough automatic theorem prover to 
check the proof steps corresponding to the recursion structure of 
the evidence-generating program. Case analysis on the resulting 
evidence is sufficient to persuade GHC that sorting invariants hold 
and that boxes snap together. In this respect, Haskell handles simple 
proofs much more neatly than Agda, where proof is as explicit as 
programming because it is programming. There is still room for 
improvement: we do not yet have a compositional way to express 
just the fact that properties follow by a common proof pattern in a 
way that GHC will silently check. 

There is room for improvement also in the treatment of de- 
pendent quantification, both in Haskell and in dependently typed 
programming languages. Haskell naturally gives good support for 
quantifying over data which are purely static, whilst Agda insists 
on retaining these data at run time. Meanwhile, the singletons 
shenanigans required to support the dynamic quantifiers are re- 
ally quite painful, both conceptually — with the explosion of Nat, 
Natty, NATTY and WNat — and in the practicalities of shuffling 



between them, spending effort on converting values into singletons 
and singletons into dictionaries containing exact copies of those 
singletons. If we want to build a scalable technology with the pre- 
cision of indexing we have shown in our examples, we had better 
look for foundations which allow the elimination of this complex- 
ity, not just the encoding of it. 

The key step which we must take is to move on from Milner's 
alignment of coincidences and stop working as if a single depen- 
dent static implicit quantifier over types is all we need. We have 
encoded quantification over the same type in different ways by ab- 
stracting over different types in the same way, and the result is 
predictably and, we hope, preventably unpleasant. The Strathclyde 
team are actively exploring the remedy — generalizing the quanti- 
fier to reflect its true diversity, and allowing each type to be used 
unduplicated wherever it is meaningful. The best thing about bang- 
ing your head off a brick wall is stopping. 
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